1. Field of the Invention
This invention relates to debugging computer systems, and more particularly to a debugging engine that is resident in the hardware/software interface segment of memory on a development computing system and communicates debugging information to a remote host computer via a parallel port on the development system.
2. Background Art
BIOS Background
The architecture of most computers is generally defined by functional layers. The lowest layer is the hardware-the actual machine. The highest layer is the application program that interfaces with a user. In between the hardware and application program is the system software. The system software itself may be composed of several elements, including: the operating system kernel and shell, device drivers, and, perhaps, a multitasking supervisor.
Most architectures also include a low-level software layer between the hardware and the system software, called BIOS--Basic Input/Output System. The BIOS insulates the system and application software from the hardware by providing primitive I/O services and by handling interrupts issued by the computing system. Most computing systems are mainly controlled through the use of interrupts. Interrupts can be generated by the microprocessor, by the system hardware, or by software. The BIOS provides a logical handling of the interrupt signals. When an interrupt occurs, control of the computer is transferred to an interrupt vector which defines the "segment:offset" address of the routing in BIOS assigned to the given interrupt number.
BIOS Interrupt Service Routines (ISRs) handle interrupts issued by hardware devices. ISRs use registers in the microprocessor and BIOS data areas. The BIOS Device Service Routines (DSRs) handle software interrupts issued by the INT instruction.
The BIOS generally uses three data areas in RAM, including the Interrupt Vector Table, the BIOS Data Area, and the Extended BIOS Data Area (e.g., for power management). The BIOS also uses various input/output (I/O) ports.
BIOS Debugging
Debugging a computer system at the BIOS level is conventionally done with an in-circuit emulator (ICE). An ICE physically replaces the CPU in the development or target machine. The ICE is connected to the development machine through one buffer and with the host computer through another buffer. BIOS commands are received by the ICE through the buffers and processed by RAM resident in the ICE. The development computer BIOS accesses the ICE RAM exactly as if it was on the development machine. Attempts have been made to make ICE machines faster in order to handle debugging processing requirements. See for example, U.S. Pat. No. 4,674,089 (Poret, et al.) that discloses an improved very large scale integrated ICE that attaches to the motherboard.
ICE technology has many severe limitations. For example, ICE software is platform or CPU-specific and very expensive (around $50,000 per platform). An ICE tester is large and requires physical setup (removal of target CPU). This also necessitates a socket on the target machine for hookup. In addition, system specific ICE software may not be available when a new chip enters the market, thus ICE testing of development systems using the new chip are not possible.
Some modifications to minimize the amount of external circuitry required have been made in various debug peripherals or daughter boards. See, for example, U.S. Pat. No. 5,053,949 (Allison et al.) or U.S. Pat. No. 5,047,926 (Kuo, et at.). However, these systems still required a physical connection to the development machine CPU memory space, e.g., via CPU TAP, an internal CPU data bus connection, or ROM (read only memory) socket, and also require peripheral buffers.
Software debugging programs, such as Soft-ICE, allow for analysis of application-issued BIOS commands. However, these systems assume fully functional hardware, microprocessor, memory, stack, BIOS, and operating system on the development machine. Only BIOS commands to/from the application program are analyzed.
Limitations of the prior art reveal the need for a BIOS-level real-time debugger that is resident on the development system and does not require external circuitry for the debugging interface. It would also be desirable to have a low-cost, easily installed and accessible, low-level debugger capable of communicating debugging information to a remote host computer. Furthermore, it would be desirable to have such a system on a development machine that may not have RAM, a stack, a booted operating system, power management, or otherwise be fully functional.